Lienzo de Hipótesis de Producto

Estamos cambiando cada vez más de proyectos centrados en las demandas de clientes o usuarios a proyectos enfocados en hipótesis de productos. Hay varias razones para esto.

Por un lado, se espera que implementemos nuevas funciones en plazos cada vez más cortos. Eso se debe a que la competencia se está volviendo más feroz, y el mundo, gracias a la tecnología moderna, sigue acelerándose y volviéndose más complejo.

Por otro lado, tener grupos de usuarios más diversos significa enfrentar necesidades más diversas. Nos movemos a toda velocidad hacia un mundo completamente personalizable. Y esto genera una demanda aún mayor de ajustes instantáneos del producto.

Si las "exigencias" requieren implementación, entonces, sobre todo, las "hipótesis" necesitan ser probadas. Pero antes de eso, las hipótesis deben articularse de manera coherente. Lo cual no siempre es tan fácil como hubiésemos querido.

Creemos que cuanto más coherente sea la hipótesis, más fructífera será la prueba. En este sentido, las pruebas no solo cubren la verificación de la hipótesis actual, sino también cualquier posible perspectiva que se pueda obtener en el proceso. Para estructurar y simplificar el proceso de articular tu hipótesis, hemos destacado las siguientes preguntas, que puedes responder secuencialmente.

El lienzo de hipótesis del producto te ayuda a crear hipótesis más efectivas. Ten en cuenta que el lienzo no hace el trabajo por ti, simplemente te ayuda a concentrarte en la tarea en cuestión y a alcanzar una solución más efectiva.

Los pasos para llenar el Lienzo de Hipótesis de Producto

1. Creemos que…

Aquí describimos lo que planeamos desarrollar.

2. Para (quién)…

En este bloque, definimos nuestro público objetivo y, si es necesario, evaluamos su rol en nuestro proyecto.

Este paso es muy importante, ya que más tarde nos ayudará a clasificar nuestras hipótesis según su relevancia para nuestro proyecto. A veces, los miembros del equipo de proyectos se ven completamente seducidos por una idea interesante y terminan olvidando que solo es aplicable a unos pocos casos aislados.

De hecho, si el autor no puede explicar coherentemente a quién beneficiará su hipótesis, es muy probable que simplemente esté incurriendo en conjeturas al azar. Es como cuando un jugador de billar rompe con un golpe potente, esperando meter una bola al azar. De la misma manera, los gerentes de producto y diseñadores generan hipótesis sin conexión con los usuarios, esperando que al menos alguien muestre interés. Ten mucho cuidado con tales hipótesis; podría valer la pena dedicar tiempo a analizarlas en mayor detalle.

3. Para lograr…

También es importante determinar qué tipo de resultado esperamos de nuestro experimento. Además, el resultado debería ser preferentemente medible en términos específicos. No escribas: "¡Debemos hacerlo mejor!" Es mejor expresar tus expectativas como, “Debemos mejorar [product] en un 5%.”

Dependiendo de la hipótesis, podemos tener diferentes expectativas para los resultados a corto y largo plazo. Muchas personas prefieren centrarse en resultados a corto plazo y evitan trabajar con hipótesis que tienen objetivos más ambiciosos. Pero cuando creamos nuestra hipótesis, debemos ser conscientes de cuánto tiempo tomará probarla: un día, una semana, un mes o quizás incluso más. Con eso en mente, más adelante podremos planificar un backlog de nuestro experimento.

4. ¿Cómo medimos esto?

La capacidad de medir los resultados es el parámetro clave para probar hipótesis de productos. Si bien ya mencionamos lo que vamos a medir en el paso anterior, aquí describimos los tipos de herramientas que vamos a utilizar para esto. ¿Qué señales indicarán que la oportunidad que hemos creado es impactante? ¿Qué indicadores clave de rendimiento (cualitativos o cuantitativos) vamos a medir para demostrar que nuestro experimento fue exitoso?

5. Impacto, positivo o negativo

Hemos introducido este bloque en caso de que queramos abordar nuestra hipótesis como algo más allá de un solo objetivo. No es obligatorio completarlo.

En algunos casos, la introducción de una determinada función tiene un impacto negativo en otros parámetros dentro del sistema. Por ejemplo, añadimos una presentación extensa e informativa

a nuestra página de inicio, esperando aumentar el compromiso de los usuarios. No obstante, la presentación afecta la velocidad de carga de la página, lo que, contrariamente a nuestra intención, incrementa la tasa de rebote, potencialmente reduciendo el compromiso. En este caso específico, es probable que la mayor tasa de rebote no sea causada por la propia funcionalidad, sino por su pesadez y mala implementación.